Subject: Re: Flow Control separation.

From: Paul Brittain <[email-masked]>
Date: Fri, 16 Dec 94 13:39:00 GMT

Peter,

Thanks for checking with Gene.  As he is concerned about IFCMs having to 
flow after the ICR_cs and RA, can I suggest a compromise:

The signal that gives us the greatest problem in trying to achieve 
separation of Flow Control is the CUR_cs.  If we can disallow any Flow 
Control on that mesage we can handle FCINDs flowing on the ICR_cs and RA. 
 This prevents the need for the extra IFCMs but also prevents the first 
FCIND flowing in either direction before the circuit ID (and hence, 
potentially, the control blocks) are set up.  The circuit IDs are fixed on 
the ICR_cs and RA so these look like the first sensible point to allow 
FCINDs as every implementation must have sorted out its routing of the 
circuit traffic by then in order to fix the circuit IDs as per section 3.3.

The only change to the document required for this is to alter the table of 
permitted messages in section 8.2 to exclude any Flow Control on the CUR_cs 
and to allow only an FCIND on the ICR_cs (an ACK make no sense at this point 
in the same way as it used not to for the CUR_CS).

How does this sound?

Paul Brittain
Data Connection

 ----------
>From: aiw-dall
>To: pjb
>Subject: Re: Flow Control curve ball...
>Date: Thursday, December 15, 1994 9:16PM
>
>Return-Path: <[email-masked]>
>Received: from datcon.co.uk by postoffice.datcon.co.uk id
>    <[email-masked]>; Fri, 16 Dec 94 02:15:35 GMT
>Received: from www.raleigh.ibm.com by datcon.co.uk (4.1/SMI-4.1) id 
AA28088;
>    Fri, 16 Dec 94 02:15:07 GMT
>Errors-To: [email-masked]
>Received: from localhost.ncren.net by www.raleigh.ibm.com (AIX 3.2/UCB
>    5.64/4.03) id AA15167; Thu, 15 Dec 1994 21:16:30 -0500
>Date: Thu, 15 Dec 1994 21:16:30 -0500
>Message-Id: <[email-masked]>
>Errors-To: [email-masked]
>Reply-To: [email-masked]
>Originator: [email-masked]
>Sender: [email-masked]
>Precedence: bulk
>From: "Peter W. Gayek" <[email-masked]>
>To: [email-masked]
>Subject: Re: Flow Control curve ball...
>X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>X-Comment:  All AIW DLSw related groups
>---------------------------------------------------------------------------  
 ---
>I checked with Gene Cox since he originated the piggy-backing idea,
>and one key concern was the number of frames that have to flow
>to get a circuit up and running, especially for NetBIOS.  I continue
>to feel that adding two IFCM frames to the bring-up flow would
>cause extra delay that should not be required.  Another approach
>would be to back off on the "initial grant owed" policy and
>have a new circuit start with an implicit initial 1-window grant.
>We could get rid of the piggy-backing that way and perhaps meet
>Paul's requirement, although I know Shannon and others were very
>much in favor of the "grant owed" policy.
>
>Pandian makes a good point about circuit id's and IFCMs.  I disagree
>though about the initial window size needing to acommodate circuit
>setup and XIDFRAME messages.  None of these messages are paced, so
>they go "for free" and are not counted.  If there is text in draft
>15 that suggests otherwise, could you point it out, Pandian, so we
>can clarify this?
>
>
>Peter Gayek
>

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Fri, 16 Dec 94 10:58:10 PST

> in the same way as it used not to for the CUR_CS).

sounds good to me.
Could we come to consensus on this issue, irrespective of what we
all converge, real fast please?

Another approach from peter's comment :
-------------------------------------

> >much in favor of the "grant owed" policy.
	I am too.

	The reason is that I am not very comfortable in 
	using a value we get during CapXchg
	for all circuits that mux thru that TCP connection.
	One might want to regulate(actually stop?)
	the initial grants depending on 
	the number of circuits flowing at that time instant.

	It gives the implementors freedom to do some sort of a "slow start"
	mechanism found in TCP by atleast delaying the initial grant.
	
	(I am going to ask Santa this Xmas to give us back the 
	assignment operator!)

> >cause extra delay that should not be required.  

-- 
G. Pandian             		+ Gnanaprakasam Pandian      +
Cisco Systems, Inc.    		+ Software Engineer          +           
190, W. Tasman Drive, Bldg E   	+ Phone : (408)526-7684      +
San Jose               		+ FAX   : (408)526-8959      +
CA 95134               		+ E-mail: [email-masked] +